Use pnpm - #26

Scope the pnpm migration to the runtime itself: restore
sample_actor_ts's package-lock.json, package.json and Dockerfile to
their pre-migration state, drop its pnpm lockfile/workspace files, and
revert the e2e dev-folder suite's host-side install/build of the
throwaway Actor copy back to npm. The sample Actor mirrors a real
user's npm-based Actor, which is exactly what the runtime has to be
able to build and run; the README's "Package manager" section now
documents that boundary.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019q2fDbjWNpEC6zmuEYpwBY

The macOS startup failure ("Cannot find module
'@crawlee/fs-storage-native-linux-arm64-gnu'") is not a lockfile or
package-manager problem: @crawlee/fs-storage-native publishes bindings
only for darwin-arm64, darwin-x64, linux-x64-gnu and win32-x64-msvc -
no linux-arm64 build exists on npm at any version, including the
current v4 dist-tag - and @crawlee/fs-storage has no non-native
fallback. Docker Desktop on Apple Silicon builds linux/arm64 images by
default, so the runtime image had no binding to load. (The addon's
error text blames npm bug #4828; that is napi-rs's generic message and
a red herring here.)

Pin --platform=linux/amd64 on both Dockerfile stages: on Apple Silicon
the image builds and runs under Rosetta, on amd64 hosts (CI included)
the pin is a no-op. Actor containers are unaffected - the runtime
builds those from their own Dockerfiles at the host's native platform.
Document the constraint in requirements/system.md next to the existing
glibc one, and in the README's quick start.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019q2fDbjWNpEC6zmuEYpwBY

The FROM --platform=linux/amd64 pin is deliberate (no linux-arm64
binding of @crawlee/fs-storage-native exists), so BuildKit's
FromPlatformFlagConstDisallowed warning is a false alarm that would
greet every Apple Silicon user on plain `docker build`. Skip it via
the `check` parser directive so the same commands stay clean on every
platform.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019q2fDbjWNpEC6zmuEYpwBY

pnpm-workspace.yaml existed only to hold ignoredBuiltDependencies; the
`pnpm` field in package.json holds it just as well (the earlier install
warning that suggested otherwise came from stale node_modules state,
confirmed by a clean fresh install), so the extra file is gone and the
Dockerfile no longer copies it. Also drop the README's "Package
manager" section - implementation detail; the Dockerfile comment now
carries the one-line reason for pnpm itself.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019q2fDbjWNpEC6zmuEYpwBY

@crawlee/fs-storage-native 0.1.5-beta.19 is the first release with
linux-arm64 bindings (apify/crawlee-storage#72 - packaging only: its
published index.js/index.d.ts are byte-identical to 0.1.5-beta.18's),
so the runtime image no longer needs the --platform=linux/amd64 pin or
Rosetta: drop the pin and its BuildKit check directive, and let the
image build natively on both amd64 and arm64 hosts.

Every released @crawlee/fs-storage (4.0.0-beta.145 and 4.0.0-rc.0
alike) still exact-pins the arm64-less 0.1.5-beta.18, so a pnpm
override forces 0.1.5-beta.19 until a crawlee release depends on it
on its own - the README's crawlee-bump section says when to delete it.

Also bump the pinned @crawlee/core + @crawlee/fs-storage to the
current v4 dist-tag (4.0.0-beta.133 -> 4.0.0-beta.145, in lockstep per
the README) and update requirements/system.md's platform bullets.
Validated: build, lint, format, and all 335 unit + integration tests
pass against the new versions, exercising the overridden native addon.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019q2fDbjWNpEC6zmuEYpwBY